REMARKS 

The Applicants respectfully maintain that they have amended the specification and claims 
to overcome all of the objections and rejections asserted by the Examiner in the Office Action 
mailed August 28, 2002. Reconsideration and Rexamination is respectfully requested. 

DRAWING OBJECTIONS 

In the Office Action, the Examiner asserts an objection to the Figures in paragraph 1 of the 
Office Action that is related to the item "unitin module 40" and "uninit module 404" found in two 
places within the specification. In response, the Applicants have amended the specification to 
conform to the item numbers shown in Fig. 4. Withdrawal of this objection is requested. 

SPECIFICATION OBJECTIONS 

In the Office Action, the Examiner asserts an objection to the Specification in paragraph 2 
of the Office Action that is related to commonly assigned and co-pending applications identified in 
the first parargraph of the specification. Specifically, the Examiner objects to the lack of serial 
numbers for these related applications that were not know at the time of filing. In response, the 
Apphcants have amended the specification to add the requested information. 

35 U.S.C. 1 12 REJECTIONS 

In the Office Action at paragraph 4, the Examiner asserts an rejection under 35 U.S.C. 1 12, 
first paragraph, rejecting claim 27, asserting that they contain subject matter that is not adequately 
described in the Specification. In response, the Applicants respectfully point the Examiner to Fig. 2 
and the corresponding description found within the specification. The Applicants specifically 
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maintain that the discussion of pages 1 1-12 of the specification regarding the networking of 
computing systems is sufficient to enable one of ordinary skill in the art to make and use the 
invention recited within claim 27. One skilled in the art knows that programs that are encoded may 
be transmitted between networked computers and this application as filed is sufficient to enable 
claim 27. As a result, withdrawal of the rejection is requested. 

35 U.S.C. 102 REJECTIONS 

In the Office Action at paragraph 5, the Examiner asserts an rejection under 35 U.S.C. 
102(a), rejecting claims 1-3, 5-6, and 18-19, asserting that they are anticipated by Guinther et al. 
(US 6,016,466). Guinther teaches a software performance profiling system. This type of system is 
similar to the prior art profiling systems expressly described within the background section of the 
application at pages 1-3. The independent claims 1,13 and 18 have been amended herein to clarify 
the differences noted in the application between prior profiling systems in which instrumentation 
code is inserted for testing and the claimed invention that permanently inserts performance markers 
into the final product so that the performance testing is performed on a version of an application 
that is identical to the version that is ultimately considered the delivered product. Guinther teaches 
the process of instrumenting portions of software that is of interest where testing is to occur. The 
teachings expressly make a distinction between "instrumented" code and "uninstrumented" code. 
See Col. 15, lines 21-36 as one example. 

In contrast, the claimed invention utilizes performance markers that are permanently 
inserted into application programs that are used in testing, benchmarking, and profiling the 
operation of the software. These performance markers are intended to be in the final version of the 
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software that is ultimately delivered to end users. The Guinther distinction between uninstumented 
and instrumented code is consisted with all prior art systems where the instrumentation code is 
added for the purposes of testing and made to impose little or no impact upon the performance 
measures created by the instrumentation code. However, the application program is in fact 
modified to insert the instrumentation code in place of uninstrumented code. In contrast, the 
claimed invention, as amended, requires the permanent insertion of performance markers into the 
application programs that impose little if any overhead to operate, and thus are not removed from 
the application program when the application has completed its testing. As such, Guinther does not 
anticipate the claimed invention, as amended, that is recited within independent claims 1, 13, and 
18. 

Dependent claims 2-3, 5-6 and 19 recite additional limitations that further distinguish the 
claime invention from the teaching found in Guinther and are also allowable for at least the same 
reasons recited above. 
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35 U.S,C. 103 REJECTIONS 

In the Office Action at paragraph 6, the Examiner asserts an rejection under 35 U.S.C. 103, 
rejecting claims 7-12 and 23-26, asserting that they are unpatentable over Guinther et al (US 
6,016,466) in Ught of LevineetaL (US 6,349,406). The Examiner cites Levine for a teaching of 
subtracting an estimate of an overhead associated with the use of instrumentation code to determine 
the performance measurements for the actual appUcation program. The claims rejected unde r35 
U.S.C. 103 all depend fi-om the independent claims discussed above. For the reasons stated above, 
these claims are patentable over Guinther for at least the reasons stated above. Levine does not 
remedy this deficiency in Guinther . In fact, Levine teaches away fi^om the permanent insertion of 
performance markers into an application program. As noted in Col. 8, Levine teaches the use of a 
JAVA interpreter that is itself instrumented such that performance measures may be obtained. 
From this, Levine expressly notes that application program itself does not include such markers. 
Therefore, Levine may not be combined with any teaching for a system in which the use of 
permanent performance markers are included within an application program. These claims are now 
patentable over the prior art of record for at least these reasons. 

DOUBLE PATENTING REJECTION 

In paragraph 7 of the Office action, the Examiner asserts a provisional double patenting 
rejection for the claims in this application with the related application, Serial No. 09/606,896. This 
application is commonly assigned and the Applicants will submit a terminal disclaimer in this 
application upon receipt of an indication that the applications are otherwise allowable. If the 
Examiner wishes to request these prior to the entry of the next Office Action because the 



applications are deemed otherwise allowable, the Applicants respectfully request the Examiner 
contact the undersigned counsel and such terminal disclaimers will be provided to place both 
applications in condition for allowance. 



CONCLUSION 



For all of the above reasons, the Applicants respectfully maintain that the pending claims, 
as amended, are now patentable over the prior art of record. For these reasons, the Applicants 
respectfully request that the above objections and rejections be withdrawn and the application be 
passed for allowance. 

Respectfully submitted, 
MERCHANT & GOULD P.C. 
P.O. Box 2903 

MinneapoUs, Minnesota 55402-0903 
332-5300 



Date: 




lichard J. Gre 
Reg. No. 41,804 
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Serial No. 09/606,896 
VERSION WITH MARKINGS TO SHOW CHANGES MADE 
In the Specification 

Please amend the specification to replace the paragraphs indicated below with following 
text. No New Matter is being added in this amendment. 

Please amend the paragraph found on page 1, lines 5-10 as follows: 

The instant application is related to two concurrently assigned and concurrently filed U.S. 
Patent Applications, Performance Markers to Measure Performance of Features in a 

Program, Serial No. [ ] 09/606,961 , filed [ ] June 29, 2000 , (Attorney Docket 

M&G 40062.69-US-Ol) and Performance Markers to Measure Benchmark Timing of 

Features in a Program, Serial No. [ ] 09/606,925 , filed [ ] June 29, 2000 , 

(Attorney Docket No. 40062.69-US-02). — 

Please also amend the paragraph found at page 13, lines 7-18 as follows: 

Fig. 3 illustrates another application program testing system according to another 
embodiment of the present invention. An application program 101 being tested consists of an 
application main body module 301, one or more application specifically defined linked libraries 
302-304, one more application specifically defined dynamically [link] linked libraries 312-314, a 
performance benchmark statically linked library 305, and a performance benchmark dynamically 
linked library 315. In the past, application programs typically consisted of all the above modules 
with the exception of the performance benchmark statically linked library 305 and the 
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performance benchmark dynamically linked library 315. An application developer who writes 
the application program 101 has specified a collection of processing modules, which may not be 
organized into the various libraries. These modules are combined together to create the 
appHcation program 101 that the application developer wishes to test. 

Please also amend the paragraph found at page 17, line 15 through page 18, line 2 as follows: 

Once all the processing has been completed, the unlnit module [404] 403 is called using 
unlnit call 413. This module [404] 403 also checks to determine if the Init module 401 has 
indicated that benchmark processing is to occur. If this benchmark processing is not to occur, the 
linked unlnit module [404] 403 simply retums to the application program 101. If the benchmark 
processing is to occur, the linked uninit module [404] 403 calls the corresponding unlnit DLL 
module 423. The unlnit DLL 423 module retrieves all of the benchmark data records from the 
memory block 424, formats them appropriately, and stores these records within the mass storage 
device 111. Once these records reach the mass storage device 111, further analysis, review, and 
subsequent processing may be performed by the application developer as needed. ~ 
In the Claims 

Please amend claims 1, 16, 20 and 24 as shown below: 

1 . (ONCE AMEDED) A computing system having a mass storage device and a 
system timer for obtaining benchmark timing for a portion of an application program execution^ 
the application program having permanently inserted performance markers , the computing 
system comprising: 

a mass storage system; 
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an init module for determining if the timestamp data is to be collected during the 
operation of the application program; 

a performance marker module for obtaining and storing the timestamp data for later 
retrieval at predefined points corresponding to the permanently inserted performance markers ; 

an uninit module for formatting and storing the obtained timestamp data into a data file 
within the mass storage device that permits retrieval after the termination of the application 
program; and 

a performance benchmark data post processing module for determining the benchmark 
timing fi"om two or more timestamp data entries; 
wherein 

the init module is executed before any timestamp data is collected; 
the performance marker module is executed each time benchmark timestamp data 
and overhead timestamp data is to be collected; 

the uninit module is executed after all timestamp data desired has been collected; 

and 

the performance benchmark data post processing module determines the benchmark 
timing fi-om timestamp entries stored within the data file. 

13. (ONCE AMENDED) A method for obtaining benchmark timing for a portion of 
an application program execution, the method comprising: 
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permanently inserting one or more code markers into the application program at locations 
within the application program corresponding to the point at which benchmark timing data is 
desired; 

determining if benchmark timing data is to be collected at each code marker by checking 
for the existence of processing modules identified by an identification key within a system 
registry; 

if benchmark timing data is to be collected at each code marker: 

generating a benchmark data record containing the collected benchmark timing 
data each time the code markers are reached; 

storing the benchmark data records within a data memory block within the 
processing modules identified by the identification key within the system registry; 

retrieving the benchmark data records from the data memory block for transfer to 
a mass storage device once all of the run-time intemal state data has been collected; and 
processing the benchmark data records stored within the mass storage device to determine the 
benchmark timing defined between two benchmark data records. 

1 8. (ONCE AMENDED) A computer data product readable by a computing system 
and encoding a computer program of instructions for executing a computer process for obtaining 
run-time intemal state data within an application program, said computer process comprising the 
steps of: 
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permanently inserting one or more code markers into the application program at locations 
within the application program corresponding to the point at which benchmark timing data is 
desired; 

Determining if benchmark timing data is to be collected at each code marker by checking 
for the existence of processing modules identified by an identification key within a system 
registry; 

if benchmark timing data is to be collected at each code marker: 

generating a benchmark data record containing the collected benchmark timing 
data each time the code markers are reached; 

storing the benchmark data records within a data memory block within the 
processing modules identified by the identification key within the system registry; 

retrieving the benchmark data records fi-om the data memory block for transfer to 
a mass storage device once all of the run-time internal state data has been collected; and 

processing the benchmark data records stored within the mass storage device to 
determine the benchmark timing defined between two benchmark data records. 
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